Systems and Methods for Improved Database Intelligence

ABSTRACT

Systems and methods for utilizing a single sequence of operations for querying data and processing operations on the data when that is stored in an extended form of predicate logic are described herein. The systems and methods described herein may support storing, querying, and performing operations on data stored in a form of predicate logic that is extended to include quoting. The inclusion of quoting enables predicate logic to store data about queries and rules, thereby allowing queries and operations on data about queries and rules. This extended form of data in combination with the infrastructure described herein allows for the creation of entire applications that are defined in the same data language as the data process by that application. This creates a unified infrastructure that enables user to query, analyze, and process both applications and the data processed by those applications via a common method.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application No.62/903,258, filed Sep. 20, 2019, entitled “Systems and Methods forImproved Database Intelligence,” the contents of which is incorporatedherein by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to storing, querying, and performingoperations on data stored in a form of predicate logic extended toinclude quotation.

BACKGROUND OF THE INVENTION

In computational languages, there is a divide between queries and thelanguages in which data is stored. Specifically, queries are formed inone language and data is stored in another language. For example, theExtensible Markup Language (XML) is a data language that is distinctfrom XQuery (or XML Query)—the language used to query and process XMLdocuments. This means that an XQuery expression is not a valid XMLexpression, and vice versa. For databases, there is an even broaderdivide. The Structured Query Language (SQL) defines instructions formanipulating databases, but there is no standard language or format forthe data itself—only references to the tables and columns which organizethe data are part of the language.

That limitation entails that these query languages are incapable ofasking queries about queries written in that language. For example, theSQL language has not been designed to support formulating an SQL querythat analyzes other SQL statements. For example, using the core featuresof the SQL language, there is no way to take a list of SQL statementsand extract what tables and columns they were accessing or to identifywhich statements in the list are accessing a given table. A consequenceof this divide is that queries themselves cannot be treated as data.

This disconnect may be compounded when a system combines query languageswith other programming languages. For example, an application could bewritten in the Java programming language and interact with a databaseusing SQL. The Java application would programmatically create andexecute SQL queries. Within current query languages, there is no way toanalyze other languages to see what queries are being constructed. Inthe above example, SQL has no capability to process Java code and toidentify the SQL queries that are part of a program.

This technical problem has practical implications for security, privacy,and compliance practices and legal requirements. Protecting datarequires understanding what is and what can happen within a system.However, protection goes beyond the basics of security which focuses onunauthorized changes to data. Privacy and other forms of compliance caninclude auditing systems to document the data which a system contains,what actions can be performed on it, and who can perform which actions.

As an example, the Privacy Act of 1974 established requirements forfederal agencies regarding how personal information is collected,managed, and utilized. A central trigger for Privacy Act compliance(e.g., under 5 U.S.C. § 552) is how information is accessed.Specifically, if an individual's information is accessed via thatperson's name, an assigned identifier. or some other attribute(s) (e.g.,a photograph), then that collection of information becomes a “system ofrecords” and triggers a range of requirements. This definition entailsthat a given database constitutes a Privacy Act system of records notbased on just the data it contains, but also on how that data isaccessed. For organizations covered by the Privacy Act, a properdetermination of compliance requires understanding both the contentwithin a database and how applications access it. The practicalimplications of the technical problem described herein arises with theneeded steps to complete a Privacy Act compliance evaluation.

Because current query languages are unable to treat queries as data, thevarious options to complete an evaluation required under the Privacy Actmay rely on some combination of manual effort and trust. This reliancestems from the lack of a technical solution that would allow someone,who we will call an auditor, to query an application's code and how itinteracts with the database to determine if its design triggers PrivacyAct requirements.

The most direct form of evaluation is a manual review. For example, anauditor may manually review the code itself to reconstruct its behaviorand interactions with the database. In theory, this would allow theauditor to fully understand the behavior of the system. However, thereare numerous problems that prevent this from being an effectiveapproach. First, a manual review is prone to error due to the complexityof the task. Second, a manual review is time and resource intensive. Thetime to complete the evaluation grows with the size of the system.Further, it requires the auditor to have similar skills and knowledge asthe team that developed the system. Finally, there are a range ofcomplications around the code itself, such as an organization beinggranted access to source code and the source code' s understandabilitybased on how clearly it was written and documented. There aredevelopment tools to help improve the efficiency of software engineerswork with source code by providing search, debug, and profiling tools.These provide some help, but do not solve the problem that theevaluation depends on the auditor manually reviewing and understandingthe code as it relates to legal, regulatory, or policy considerations,and then delivering an accurate evaluation.

Alternatively, the auditor could seek to indirectly evaluate a systemvia interviews and documentation reviews. With this approach, theauditor may interview the development team and review availabledocumentation about its design and implementation to understand theinformation stored within the system and how it is utilized.Fundamentally, this approach relies on a degree of trust. The auditormust trust the interviews/interviewees and the documentation to delivera complete and accurate description of the system. The trustworthinessof the team and the documentation is complicated by the many changesthat systems and teams undergo. For example, the team members that builta given system may no longer be available when an evaluation is beingperformed, and new team members may not know or understand the system'sfull details. Further, as the system changes over time with updates,extensions, or fixes, the documentation may not reflect the currentstate of the system. Understanding these changes are essential tomanaging and protecting data within these systems and being able toevaluate systems' compliance with an organization's policies or laws andregulations covering the data they contain.

These various technical limitations and other drawbacks of conventionalquery languages leave organizations unable to have an automated andrepeatable process for evaluating and auditing their systems. Atechnical solution is needed to address the inability of conventionalquery languages to run queries about queries and other operations.

SUMMARY OF THE INVENTION

Various embodiments of the present disclosure may include systems andmethods configured to utilize a single sequence of operations forquerying data and processing operations on the data. The systems andmethods described herein may utilize a form of predicate logic extendedto include quotation that enables ordinary data to be stored along withdata about queries and rules, thereby allowing queries and operations ondata about queries and rules. Predicate logic stores data in the form ofindividual sentences (declarative statements) and there is a broad rangeof terms which can be used to construct these sentences. The systemconfigured to utilize this extended form of predicate logic may include,for example, a data server, an inference engine, a query server, anoperation server, and/or one or more other components.

The data server may comprise a device configured to store data in theform of predicate logic sentences. It may use a variety of methods fororganizing the stored data. The data server may be configured to supportcore operations for adding, removing, and modifying the statements thatit stores. It may also support queries by enabling the matching of queryformulas against stored sentences and support deductions by matchingantecedent formulas against stored sentences.

The query server may comprise a device configured to process namedqueries (i.e., functional terms from which a fully-formed query can bededuced based on rules that connect terms in the functional term topositions in a templated query) given as inputs by external,authenticated entities. The query server performs a sequence ofinteractions with an inference engine, which is either internal to thequery server device or accessible via a network connection. In variousimplementations, the sequence of interactions may include two steps.First, the query server uses the inference engine to determine if theexternal entity is authorized to run the named query based on the user,the functor of the named query, and/or its terms. If the named querypasses the first step, the query server may run the named query usingthe inference engine and returns the results to the authenticatedentity.

The operation server may comprise a device configured to process namedoperations (i.e., functional terms from which fully formed-statements toadd or delete can be deduced based on rules that connect terms in thefunctional term to positions in the fully-formed statement) given asinputs by external, authenticated entities. The operation server may beconfigured to perform a sequence of interactions with an inferenceengine module, which is either internal to the operation server deviceor accessible via a network connection, and an associated data server,which is accessible via a network connection. In variousimplementations, the sequence of interactions may include four steps.First, the operation server uses the inference engine to determine ifthe external entity is authorized to perform the named operation basedon the user, the functor of the named operation, and/or its terms. Ifthe named operation passes the first step, then the operation server mayuse the inference engine to check that the named operation satisfiesdata integrity rules associated with the functor of the named operation.If the second step succeeds, the third step may then be to use theinference engine to deduce the sentences to add, remove, or delete fromthe data server. The final step may be to actually make the additions,deletions, or modifications to the data server.

The inference engine may comprise a device configured to performinferences using the data server. The inference engine may have twospecific behaviors: processing named queries and processing namedoperations. The inference engine may be configured to take the namedquery or operation and performs two steps. First, it may run aninference to determine the corresponding full query for the named queryor operation. Second, it determines what rule statements, if any, shouldsupport the full query and how those rule statements fit together (i.e.,how the consequents of one rule statement links the antecedent ofanother).

The process may begin with the query. Rule statements whose consequentformulas which can be linked to formulas in the query are connectedfirst. Rule statements are recursively linked to other rule statements,where the formulas in the antecedents of earlier rule statements arelinked to formulas in the consequents of later rules. The result is atree like structure of connected rule statements, which we will call an“inference tree.” The inference engine may be configured to processesthe inference tree using the content of the data server. The processworks from the rules that are at the leaves of inference tree (i.e.,their antecedents are not connect to any other rule statements). In thissituation, there are no deduced sentences which the inference engine islooking for. It may be configured to only use statements that are storedwithin the data server and then deduce new statements based on theterminal rule statements. At this point, there can be deduced statementsand stored statements within the Data Server. Both sets of statementsare now used for subsequent deductions performed with non-terminal rulestatements. This process may recurse through the tree structure untilresults are being fed into the formulas within the query at the base ofthe inference tree. When this process finishes, a set of results areprovided for the query.

These and other objects, features, and characteristics of the systemand/or method disclosed herein, as well as the methods of operation andfunctions of the related elements of structure and the combination ofparts and economies of manufacture, will become more apparent uponconsideration of the following description and the appended claims withreference to the accompanying drawings, all of which form a part of thisspecification, wherein like reference numerals designate correspondingparts in the various figures. It is to be expressly understood, however,that the drawings are for the purpose of illustration and descriptiononly and are not intended as a definition of the limits of theinvention. As used in the specification and in the claims, the singularform of “a”, “an”, and “the” include plural referents unless the contextclearly dictates otherwise.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings are provided for purposes of illustration only and merelydepict typical or example implementations. These drawings are providedto facilitate the reader's understanding and shall not be consideredlimiting of the breadth, scope, or applicability of the disclosure. Forclarity and ease of illustration, these drawings are not necessarilydrawn to scale.

FIG. 1 illustrates a block diagram of an example of a system forprocessing queries and operations on data stored as sentences ofpredicate logic utilizing inference trees, according to animplementation of the invention.

FIG. 2 illustrates an example of a process of receiving and processingqueries, according to an implementation of the invention.

FIG. 3 illustrates an example of a process of receiving and processingoperations, according to an implementation of the invention.

FIG. 4 illustrates an example of a process of utilizing inference treesto process named queries and operations, according to an implementationof the invention.

FIG. 5 illustrates an example of a process of executing an applicationthat has been described in data using the extended form of predicatelogic language described herein and using the inference engine toprocess both queries and operations required to process user inputs andinstantiate a page of the application, according to an implementation ofthe invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention described herein relates to systems and methods forutilizing a single sequence of operations for querying data andprocessing operations on the data when that data is stored in anextended form of predicate logic. The systems and methods describedherein may support storage, queries, and operations on data stored in aform of predicate logic that is extended to include quoting. Theinclusion of quoting enables predicate logic to store data about queriesand rules, thereby allowing queries and operations on data about queriesand rules. This extended form of data in combination with theinfrastructure described herein allows for the creation of entireapplications that are defined in the same data language as the dataprocessed by that application. This creates a unified infrastructurethat enables users to query, analyze, and process both applications andthe data processed by those applications via a common method.

It will be appreciated by those having skill in the art that theimplementations described herein may be practiced without these specificdetails or with an equivalent arrangement. In various instances,well-known structures and devices are shown in block diagram form toavoid unnecessarily obscuring the implementations.

Example System Architecture

FIG. 1 illustrates a block diagram of an example of a system 100 forprocessing queries and operations on data stored as sentences ofpredicate logic utilizing inference trees, according to animplementation of the invention. In various implementations, system 100may include one or more client computing platforms 104, one or moreservers 110, electronic storage 140, and/or other components. Forexample, system 100 may include one or more external resources, such assources of information outside of system 100, external entitiesparticipating with system 100, and/or other resources.

In various implementations, one or more servers 110 (alsointerchangeably referred to herein as server(s) 110, server 110, orservers 110 for convenience) may be configured to communicate, receiveinput from, or otherwise interact with one or more client computingplatforms 104 and/or other components of system 100. Users may accesssystem 100 via client computing platform(s) 104. The server(s) 110 mayprovide the client computing platform(s) 104 with information necessaryto present user interfaces on the client computing platform(s) 104. Theclient computing platform(s) 104 may communicate information back toserver(s) 110 in order to facilitate further processing and/orfunctionality at server(s) 110. A given client computing platform 104may include one or more processors configured to execute computerprogram components. By way of non-limiting example, a given clientcomputing platform may include one or more of a desktop computer, alaptop computer, a handheld computer, a tablet computing platform, aNetBook, a Smartphone, and/or other computing platforms.

Communications may be facilitated through network(s) 102. The network(s)102 may include wired and/or wireless connections. The network(s) 102may include the Internet, Bluetooth, USB, and/or other communicationnetworks. It will be appreciated that this is not intended to belimiting and that the scope of this disclosure includes implementationsin which components of system 100 may be operatively linked via someother communication media.

In various implementations, server(s) 110 may include one or morephysical processors 112 and/or other components. The one or morephysical processors 112 (also interchangeably referred to herein asprocessor(s) 112, processor 112, or processors 112 for convenience) maybe configured to provide information processing capabilities in system100. As such, the processor(s) 112 may comprise one or more of a digitalprocessor, an analog processor, a digital circuit designed to processinformation, a central processing unit, a graphics processing unit, amicrocontroller, an analog circuit designed to process information, astate machine, and/or other mechanisms for electronically processinginformation.

In various implementations, processor(s) 112 may be configured toexecute one or more computer readable instructions 114. Executing thecomputer readable instructions 114 may cause one or more processors 112to utilize a single sequence of operations for querying and processingoperations on data stored as sentences of predicate logic. Computerreadable instructions 114 may include one or more computer programcomponents. In some implementations, computer readable instructions 114may be stored in electronic storage (e.g., electronic storage 140).Computer readable instructions 114 may include one or more of datacomponent 116, query component 118, operation component 120, inferenceengine 122, application component 124, volume manager component 126,monitor component 128, induction component 130, and/or other computerprogram components. In some implementations, computer readableinstructions 114 may further include and/or interact with one or moreservice endpoints 132, an inference tree cache 134, and/or one or moreother components. As used herein, for convenience, the various computerreadable instructions 114 will be described as performing an operation,when, in fact, the various instructions program the processor(s) 112(and therefore system 100) to perform the operation. In someimplementations, system 100 may further include one or more serviceendpoints 132

Data component 116 may be configured to store data associated withsystem 100 in the form of predicate logic sentences. In variousimplementations, data component 116 may be configured to utilize one ormore methods for organizing the stored data. In various implementations,data component 116 may be configured to support core operations foradding, removing, and/or modifying the statements (or data) stored. Invarious implementations, data component 116 may be configured to enablethe matching of query formulas against stored sentences. In variousimplementations, data component 116 may be configured to supportdeductions by matching antecedent formulas against stored sentences.

In various implementations, data component 116 may be configured tostore data only in the form of atomic sentences (i.e., sentences withoutlogical connectives or quantifiers). For example, data component 116 maybe configured to store atomic sentences in an extended form of predicatelogic described further herein. In various implementations, storedatomic sentences may comprise data, queries, inference trees, and/ordescriptions of applications. In conjunction with inference engine 122(i.e., via the operations described further herein with respect toinference engine 122), data component 116 may be configured to answerqueries by matching formulas within a query against stored atomicsentences, as described further herein. In various implementations, datacomponent 116 may comprise a data server that is separate and distinctfrom one or more of the other components of system 100.

Knowledge-based AI systems which rely on predicate logic typically storeall logical content together. As such, in implementations in whichsystem 100 comprises a knowledge-based AI system, data component 116 maybe configured to store atomic sentences along with molecular statements(i.e., statements with logical connectives) or general statements (i.e.,statements with quantifiers and variables). An example of an atomicsentence may be “(isTheFatherOf Adam Abel)”. This atomic sentence couldbe read as “Adam is the father of Abel.” An example of a molecularsentence using the “AND” logical connective may be “(isTheFatherOf AdamAbel) AND (isTheFatherOf Adam Cain)”. This molecular sentence could beread as “Adam is the father of Abel and Cain.” An example of a generalstatement with a universally quantified variable X and an existentiallyquantified variable Y may be “(For all X)(There Exists Y)(isTheFatherOfY X)”. This general statement could be read as “Everyone has a father.”Storing atomic sentences along with molecular statements or generalstatements may be based on the standard way that deductions areperformed in predicate logic, where all statements (atomic, molecular,or general) are together in a single set, and then processed throughdeductive operations. The inclusion of quotation and quotequantification may enable sentences to be made about queries and rulestatements. In particular, data component 116 may be configured to storestatements that connect the functors of named queries or namedoperations, and inference engine 122 (described herein) may beconfigured to run queries against these statements to retrieve theirassociated queries and rule statements. Accordingly, there may be noneed to store rule statements separately.

Query component 118 may be configured to receive and process namedqueries. For example, query component 118 may be configured to processnamed queries (described below) given as inputs by external,authenticated entities. In various implementations, query component 118may be configured to perform a sequence of interactions with inferenceengine 122, which may be a component of query component 118 and/oraccessible by query component 118 via a network (e.g., network 102). Invarious implementations, query component 118 may be configured toutilize inference engine 122 to determine if an external entity isauthorized to run a given query. If it is determined that the entity isauthorized, query component 118 may be configured to run the named queryusing inference engine 122 and return the results to the authenticatedentity. In various implementations, query component 118 may beconfigured to perform one or more of the operations of process 200described herein with respect to FIG. 2. In some implementations, querycomponent 118 may be configured to execute process 200 in response toreceipt of a named query. In various implementations, query component118 may comprise a query server that is separate and distinct from oneor more of the other components of system 100.

Operation component 120 may be configured to receive and process namedoperations. For example, operation component 120 may be configured toprocess named operations (described below) given as inputs by external,authenticated entities. In various implementations, operation component120 may be configured to perform a sequence of interactions withinference engine 122, which may be a component of operation component120 and/or accessible by operation component 120 via a network (e.g.,network 102). In various implementations, operation component 120 may beconfigured to utilize inference engine 122 to determine if an externalentity is authorized to perform a given operation, based on the user,the functor of the named operations, and/or its terms. If it isdetermined that the entity is authorized, operation component 120 may beconfigured to use inference engine 122 to check that the operationsatisfies data integrity rules associated with the functor and argumentsof the named operation. If it is determined that the operation satisfiesdata integrity rules associated with the functor of the named operation,operation component 120 may be configured to use inference engine 122 todeduce the sentences to add, remove, or delete from the data stored bydata component 116. Based on the sentences deduced, operation component120 may be configured to perform the operations necessary to add,remove, or delete the data stored by data component 116. In variousimplementations, operation component 120 may be configured to performone or more of the operations of process 300 described herein withrespect to FIG. 3. In some implementations, operation component 120 maybe configured to execute process 300 in response to receipt of a namedoperation. In various implementations, operation component 118 maycomprise an operation server that is separate and distinct from one ormore of the other components of system 100.

Inference engine 122 may be configured to perform inferences based on orusing data associated with system 100. For example, inference engine 122may be configured to perform inferences based on data stored by datacomponent 116. In various implementations, inference engine 122 may beconfigured to both process “named queries” and process “namedoperations” in conjunction with query component 118 and operationcomponent 120, respectively. A “named query” is a functional term whosefunctor is associated with a quoted query via data and quoted rulestatements stored via data component 122. The contents of a named queryfunctional term are parameters that may be used to configure the quotedquery. A “named operation” is very similar to a named query, but theencoding results in a query whose results specify sentences and whetherthose sentences should be added, modified, or deleted within the DataServer.

The role of named queries and named operations can be understood inanalogy to elements for common methods for implementing web services.Two recent approaches to web services are SOAP (Simple Object AccessProtocol) and REST (Representational State Transfer). In a typical SOAPimplementation, a web service is located at a network address and it hasa fixed range of methods which it supports. XML messages are sent to theweb service, indicating which method the message wants to activate andthe XML message which will be the input to the method. The SOAP messageprocesses the message and then returns another XML message. With RESTfulweb services, embedded messages can also be sent, but it also allows forthe URL used to call the web service to include embedded inputparameters for the called method (in that way, a message does not needto be sent in order to call the web service) and it also takes advantageof the semantics of the method used for communication using HypertextTransfer Protocol (HTTP).

Unlike conventional web service technologies, system 100 is not limitedto specific methods such that different instances would need to becalled for different types of queries or operations. Rather, querycomponent 118 and operation component 120 may receive any named query ornamed operation, and it is the connection of the named query or namedoperation received to the data stored by data component 116 thatdetermines what queries will be run or operations will be performed. Ifa user elects to run another query or make a different set of changes,the user can use the same query component 118 and operation component120—the user only need send in a different named query or operation.

In various implementations, inference engine 122 may be configured tofunction differently than other knowledge-based systems which utilizepredicate logic. Traditionally, those systems would receive a query,look at all available data and rule statements, and then assemble adeduction during the processing of the query. This means that the waythat an inference is completed is dependent on the specific rules thatare available when the query is asked. These systems can grow incapability as new knowledge is added to the system in the form of rulestatements because they enable new inferences to be completed. However,in the context of the technical problems described herein, this meansthat, as rule statements are added or removed from these other systems,the inferences which the system performs could change because there isno specified connection between the query and rules. By storing queriesand rules in statements, linking specific functors to the queries andrules, and performing processing with named queries or operations, thespecification of a link between queries and a fixed set of rules can beachieved. There may be a standard process where the quoted queries andrules are extracted and then assembled. The result is called an“inference tree.” The process for constructing an inference tree isdescribed further herein. In some implementations, inference engine 122may be configured store constructed inference trees for later retrievalas described herein without the need to recreate the inference tree. Forexample, inference engine 122 may be configured to store constructedinference trees for later retrieval in inference tree cache 134.

In various implementations, inference engine 122 may be configured toreceive a named query or named operation from query component 118 oroperation component 120, respectively. In various implementations,inference engine 122 may be configured to run an inference to determinethe corresponding full query for the named query or named operation.Using the common infrastructure, the full query is determined byinference engine 122, which applies a standardized query that directlyasks what the full query is for the named query. However, the answerdepends on rules associated with the functor of the named query. Theinference engine runs a standardized query to identify the associatedrules for the named query functor, then constructs and executes aninference tree based. In various implementations, inference engine 122may be configured to then determine what rule statements, if any,support the full query based at least on how those rule statements fittogether (i.e., how the consequents of one rule statement links theantecedent of another). In various implementations, inference engine 122may be configured to execute a uniform method for processing both namedqueries and named operations. For example, inference engine 122 may beconfigured to perform the operations of process 400 described hereinwith respect to FIG. 4 for each named query or named operation inferenceengine 122 receives.

In various implementations, this uniform method may begin with a query.Rule statements whose consequent formulas which can be linked toformulas in the query are connected first. Rule statements arerecursively linked to other rule statements, where the formulas in theantecedents of earlier rule statements are linked to formulas in theconsequents of later rules. The result is the inference tree—thetree-like structure of connected rule statements. The set of rules usedto assemble the inference tree are determined by a standard query basedon the functor of the named query. A shortened form of this step couldbe performed if there is a cache of previously constructed inferencetrees that could be adapted to the current named query or operation.

In various implementations, inference engine 122 may be configured toassemble the inference tree based on matching two formulas. At thebeginning, this may comprise matching a formula in the query against theconsequent formula (i.e., the formula in the THEN part of an IF-THENrule). In subsequence iterations, the matching may be between a formulaof an antecedent formula (i.e., a formula in the IF part of an IF-THENrule). The rule may be added into the inference tree and linked to theformula in cases when two formulas can be aligned. If the formulascannot be aligned, the rule may be left out of the tree for thatformula. In this discussion, the formula in the query or in theantecedent of the rule is the “source” formula, and the formula in theconsequence of the rule is the “target” formula.

Before an alignment process begins, the variables in the original queryand the candidate rules may be obfuscated. They may be given new namessuch that the sets of variables in the query and all of the rules areunique. In this way, the alignment process does not get conflatevariables that happen to appears in both the source formula and thetarget rule.

Alignment is a process for testing various ways to fit two formulastogether. Simple tests for alignment failure include determining whetherthe formulas have different numbers of arguments or whether there aredifferent constants in the same position. If the rule passes thosetests, inference engine 122 may be configured to look for ways to fitthe rules together. Considering the different types of terms in thesource formula that need to be compared against a term in the targetformula, the following cases may be found: a bound-term against avariable; a variable against a bound term; a variable against avariable; a variable against an open compound term; an open compoundterm against a variable; and an open compound term against an opencompound term. A “compound term” is a term made up of other terms, suchas a functional term or quote term. An “open compound” term is acompound term that contains open variables. A compound term thatcontains no open variables is considered a “bound term.”

The handling of each of these cases may involve two potential steps.First, inference engine 122 may be configured to modify the targetformula (and the rule which contains it) to bring over bound terms orvariables from the source formula into the target rule. For example, asource bound term may matched against a target variable. Inferenceengine 122 may then be configured to modify the target rule to replaceall occurrences of the target variable with the source bound term.Alternatively, “converters” may be added to line up the terms in twomatching positions. For example, if a source variable is matched againsta target bound term, a converter may be introduced indicating that thesource variable will always be bound to the target bound term. Differentalteration and conversion strategies may be deployed for each case.

As the alignment process proceeds, it may be possible that the neededalignment steps will reach an inconsistent state. For example, twoconverters might be required for the same source variable appearing indifferent positions, but the two converters are using different targetbound terms. In these cases, the alignment process fails because avariable could not be bound to two different terms, and the rule isexcluded from the inference tree.

If the alignment process succeeds, the process may iterate for new rulesthat could be added as branches onto the formulas in the antecedent ofthe rule that was just completed. It would be a depth first approach,adding branches on to branches before returning to the formulas in theoriginal query.

When constructed, the inference tree will have a tree structure with thequery at the root. Each formula within the query has connected to itzero or more rules. These rules would include any changes that were madeduring the alignment process. Each connection between a formula and aspecific rule would also have a set of any converters that were addedduring the alignment process.

As a simple example, consider a one formula query and a simple rule: thequery is “Who are Bob's parents?” It could be expressed as a single(source) formula:

hasParent Bob ?PARENT

Then consider a simple target rule: If someone is your father, then theyare your parent.

hasParent ?CHILD ?FATHER, IF hasFather ?CHILD ?FATHER.

After obfuscating the variables, the source formula would be:

hasParent Bob ?VAR1

and the target rule would be:

hasParent ?VAR2 ?VAR3, IF hasFather ?VAR2 ?VAR3.

After the alignment process completed, the updated target rule would be:

hasParent Bob ?VAR1, IF hasFather Bob ?VAR1.

In this example, there would be no need for converters, but the boundterm in the first position of the source formula has replaced itsmatching variable in the target rule. Additionally, the variable in thesecond position of the source formula has replaced its matching variablein the target rule.

In some implementations, inference trees may be serialized using avariety of formats that support hierarchical or tree structures. Inparticular, a query may act as the root of the hierarchy. Each queryformula would then be connected to the rules that had been aligned toit, along with a serialized form of any converters that were createdduring alignment. The rule's antecedent formulas would follow a similarstructure, where they would be connected to the rules that they had beenaligned to, along with serialized forms of any converts that werecreated during their alignment. This process may repeat for each formulain the query and each rule that was aligned to another rule.

In various implementations, inference engine 122 may be configured toprocess an inference tree using the stored data of the system (e.g., thecontent of the data server or the data stored by data component 116). Invarious implementations, inference engine 122 may be configured toprocess the inference tree using the stored data of the system, which isstored as sentences of predicate logic as described below. In variousimplementations, the process works from the rules that are at the leavesof the inference tree (i.e., their antecedents are not connected to anyother rule statements). These rules (or rule statements) that are at theleaves of the inference tree may be referred to as “terminal rulestatements.” For the terminal rule statements, there are no deducedsentences which inference engine 122 is looking for. Thus, inferenceengine 122 may only use stored statements and then deduce new statementsbased on the terminal rule statements. At this point, there can bededuced statements and stored statements within the stored data. Bothsets of statements are now used for subsequent deductions performed withnon-terminal rule statements (i.e., intermediary rule statements). Thisprocess may recurse through the tree structure until results are beingfed into the formulas within the query at the base of the inferencetree. When this process finishes, a set of results are provided for thequery.

There may be a third way that statements become available for deduction.In some implementations, inference engine 122 may include modules thatallow it to compute certain statements to enable a deduction without thestatements being deduced or stored. For example, if a rule statementrelies upon a mathematical calculation from data in other statements,that calculation could be expressed as a formula within a rulestatement. In some implementations, inference engine 122 may beconfigured to perform the calculation to determine the binding for therelevant variables, rather than storing every possible mathematicalcalculation or trying to deduce the calculation. In variousimplementations, inference engine 122 may include a wide range ofmodules for addressing these situations within its data.

Application component 124 may be configured to execute an applicationbased on the predicate logic language described herein and using theinference engine to process both queries and operations required toinstantiate a page of the application or to complete operations based onuser inputs. In various implementations, the functionality ofapplication component 124 may be divided between an application server,an application browser, and/or one or more other components.Accordingly, one or more of the operations described herein as beingperformed by the application server or the application browser may beperformed by application component 124. In various implementations,application component 124 may be configured to perform one or more ofthe operations of process 500 described herein with respect to FIG. 5.

In various implementations, system 100 may include an applicationbrowser associated with an application server. In variousimplementations, the application browser may be configured to provideuser with an interface to the application server (and, by extension, thequery server and operation server). In various implementations, theapplication browser may be configured to render pages (specifyingcontent that is the result of running queries associated with a namepages) on a display. For example, the application browser may beconfigured to render pages on a display of a client computing platform104 of a user. In various implementations, the application browser maybe configured to render pages with components which display the datareturned by a named page. A named page is a functional term that denotesa single screen within the user interface of an application. A namedpage may be associated with multiple queries that identify the elementsto appear on the screen, named queries for the data used to populatethose elements, and named operations for interactions which the user canperform (e.g., button pushes). In various implementations, thecomponents can translate human interactions with the application browser(via the page rendered on a display) into named operations or requestsfor named pages.

In various implementations, system 100 may include an application serverassociated with a query server (or query component 118) and an operationserver (or operation component 120). In various implementations, theapplication server may be configured to respond to named page requestsand named operations from application browser. In variousimplementations, the application server may be configured to interactwith a query server (or query component 118) to process any namedqueries to get the content that makes up the page denoted by a namedpage. In various implementations, the application server may beconfigured to interact with an operation server (or operation component120) to process any named operations initiated by the applicationbrowser. In various implementations, the application server may beconfigured to return page results to the application browser.

Volume manager component 126 may be configured to identify the locationof stored data. In some implementations, system 100 may include volumemanager component 126 to support scaling of the system. In someimplementations, volume manager component 126 may be configured to keeptrack of the location of data storage (e.g., different data servers) andthe collections of statements stores. In various implementations,operation component 120, inference engine 122, and/or one or more othercomponents may utilize volume manager component 126 to locate relevantstored data that is needed to run a query or perform an operation,including operations on the data itself.

Monitor component 128 may be configured to run named queries to check onthe state of data at specific points in time or in response totriggering events. In various implementations, monitor component 128 maycomprise optional modules that utilize query component 118 (orcomponents thereof). In various implementations, monitor component 128may be configured to obtain the results of a query and perform theactions which correspond to the query results. These actions may occurwithin the system (e.g., performing a named operation) or outside thesystem (e.g., sending an email notification with the results of thequery).

Induction component 130 may be configured to perform inductions togenerate new rules. Induction is the process of creating rule statementsfrom particular data (e.g., from data about a limited number ofcustomers, create new rules about an entire category of customers).Induction component 130 may comprise one or more servers or modules thatutilize query component 118 and/or operation component 120 (orcomponents thereof). In various implementation, induction component 130may be configured to utilize query component 117 to access data that maybe the basis of the induction. In some implementations, inductioncomponent 130 may be configured to evaluate the accuracy of newlygenerated rules. In some implementations, induction component 130 may beconfigured to store data related to generated rules and theirevaluations.

Service endpoint(s) 132 may comprise modules configured to translateinputs received. For example, one or more service endpoints 132 maycomprise optional modules associated with query component 118 and/oroperation component 120. The one or more service endpoints 132 may beconfigured to enable server(s) 110 to interact with other systems thatuse alternative messaging protocols. For example, one or more serviceendpoints 132 may be configured as SOAP or RESTful web services suchthat external systems have a traditional way to interact with the datastored within system 100 (e.g., data stored as sentences of predicatelogic). In some implementations, one or more service endpoints 132 maybe configured to translate inputs into named queries capable of beingrun using query component 118 and inference engine 122. In someimplementations, one or more service endpoints 132 may be configured totranslate inputs into named operations capable of being processed usingoperation component 120 and inference engine 122. In someimplementations, at least one service endpoint 132 may be required tosupport authentication and present the named query or named operation asif it were sent by an authenticated user accessing the at least oneservice endpoint 132.

Inference tree cache 134 may be configured to store inference trees forlater retrieval without requiring the recreation of the inference tree.In various implementations, inference engine 122 may be configured storeconstructed inference trees for later retrieval as described herein. Forexample, inference tree cache 134 may be configured to store serializedversions of inference trees that had been previously assembled byinference engine 122. In various implementations, serialized inferencetree stored in inference tree cache 134 may be stored in relation to thefunctor of the associated named query. In various implementations,serialized inference trees may be parameterized such that values from anamed query can be substituted into the serialized tree when it isdeserialized by inference engine 122. Serialization is used to save thesteps of constructing an inference tree. This efficiency can be improvedif the serialization was not just for a single query, but for the rangeof queries that can be defined by a named query. Based on the rules thatconnect the named query to the full query, it is possible to identifythe terms in the full query that come from the named query, as well astheir subsequent appearance in rules within the inference tree afteralignment. Those specific terms could be parameterized such that whenthe serialized tree is reconstituted, the process can reference thespecific terms in the current named query and replace the parameterswith the specific terms to give a fully specified inference tree for thenamed query.

Electronic storage 140 may comprise non-transitory storage media thatelectronically stores information. The electronic storage media ofelectronic storage 140 may be provided integrally (i.e., substantiallynon-removable) with one or more components of system 100 and/orremovable storage that is connectable to one or more components ofsystem 100 via, for example, a port (e.g., a USB port, a Firewire port,etc.) or a drive (e.g., a disk drive, etc.). Electronic storage 140 mayinclude one or more of optically readable storage media (e.g., opticaldisks, etc.), magnetically readable storage media (e.g., magnetic tape,magnetic hard drive, floppy drive, etc.), electrical charge-basedstorage media (e.g., EPROM, EEPROM, RAM, etc.), solid-state storagemedia (e.g., flash drive, etc.), and/or other electronically readablestorage media. Electronic storage 140 may include one or more virtualstorage resources (e.g., cloud storage, a virtual private network,and/or other virtual storage resources). Although electronic storage 140is shown in FIG. 1 as a single entity, this is for illustrative purposesonly. In some implementations, electronic storage 140 may comprisemultiple storage units. These storage units may be physically locatedwithin the same device, or electronic storage 140 may represent storagefunctionality of multiple devices operating in coordination.

Electronic storage 140 may store software algorithms, informationdetermined by processor(s) 112, information received from server(s) 110,information received from one or more client computing platforms 104,information received from one or more external resources, and/or otherinformation that enables server(s) 110 to function as described herein.In some implementations, data component 116 may be configured to storedata associated with system 100 in electronic storage 140. In someimplementations, volume manager component 126 may be configured tointerface with electronic storage 140 to track the location of datastored within system 100. In some implementations, electronic storage140 may be configured to store inference trees in inference tree cache134.

Example Predicate Logic Language

Predicate logic stores information in declarative sentences, sentencesthat can be true or false. There are many varieties of predicate logic.The common feature which distinguishes them from propositional logic isthat predicate logic allows for a description of the internal structureof sentences. Below is a Backus-Naur syntax for a simple predicate logiclanguage which is very similar to the language of PROLOG, but whichincludes functional terms.

character::=‘a’-‘z’|‘A’-‘Z’|‘0’-‘9’

constant::=character |character constant;

functional_term::=‘[’ term_sequence ‘]’;

term::=constant |functional_term;

term_sequence::=term |name term_sequence;

variable::=‘?’ constant;

open_term::=term |variable |open_functional_term;

open_term sequence::=open_term |open_term open_term sequence;

open_functional_term::=‘[’ open_term sequence ‘]’;

formula::=constant ‘(’ open_term sequence ‘)’;

formula sequence::=formula | formula ‘,’ formula sequence;

sentence::=constant ‘(’ term_sequence ‘)’ ‘.’;

horn_clause::=formula ‘IF’: | formula ‘IF’ formula sequence ‘.’;

The language defined above starts from the individual letters and buildsthe larger terms of the language. “Constants” are the individual wordsof the language. “Functional terms” are a type of term that isconstructed out of multiple constants but, like constants, can be usedas names. The first constant in the functional term is called the“functor.” The remaining constants are the “arguments” of the functionalterm. For example, constants may include ‘UnitedStates’ and ‘CapitalOf’.In this example, ‘CapitalOf’ would be a functor and ‘UnitedStates’ couldbe used as an argument with that functor. A functional term may becreated using the above syntax comprising: ‘[CapitalOf UnitedStates]’.That functional term would denote the capital of the United States:Washington, DC.

In this language, the “sentence” and “Horn clause” constructs are theheart of the language. Sentences are used to store data, with varioustypes of names used to denote objects and their attributes. Thesentences may not involve logical connectors. Thus, sentences alone maynot support deductions. The inclusion of Horn clauses may enablededuction. This is based on two important features associated with Hornclauses: the use of the keyword “IF” and the usage of “formulas” in thedefinition.

In the definition of the language, Horn clauses are constructed aroundthe keyword “IF”. There are two parts to a Horn clause: the head and thebody. The head is the formula to the left of the “IF” keyword. The bodyis the, potentially empty, list of sentences to the right of the “IF”keyword.

Formulas are sentence-like structures that contain variables. The use ofvariables illustrates a common feature of predicate logic called“quantification.” Quantification enables predicate logic to includestatements that do not include specific names, but which instead expressa generalization. The most common forms of quantification are“universal” and “existential.” They function like the English words“everything” and “something,” respectively. The example language shouldbe interpreted as having universal quantification for all variables.That is, each variable should be read as “every .”

Deduction may be enabled within the example language by associating itwith deduction patterns: “instantiation” and “unification.”Instantiation is the process by which all instances of a variable withina Horn clause are replaced with a name and a new Horn clause is created.Unification enables the deduction of the head sentence as a new sentencewhen all the sentences of the body are known (e.g., stated ordeducible). The table below specifies a simple deduction which theexample language supports.

Mortal (?X) IF Human (?X). Sentence 1 (All humans are mortal.) Human(Socrates). Sentence 2 (Socrates is human.) Mortal (Socrates) Sentence3, Deduced from 1 by IF Human (Socrates). Instantiation Mortal(Socrates) Sentence 4, Deduced from 2 and 3 by Unification.

The foregoing example is a rendering of the classic syllogism “All menare mortal. Socrates is a man. Therefore, Socrates is mortal.”

The example language described herein approximates the language PROLOG,but is ultimately a form of predicate logic. Predicate logic includeadditional connectives (syntactic elements that represent negations,conjunctions, disjunctions, or conditionals) and, as mentioned, usuallysupports both existential and universal quantification. As describedherein, the sentences in the logic that support deductions via somecombination of connectives and quantification in association withdeduction patterns may be referred to as “rule sentences.”

The language utilized by system 100 described herein may include one ormore extensions to conventional predicate logic. For example, thelanguage utilized by system 100 may further include dedicated classes ofexpressions for numbers, strings, and/or other potential data typeswithin the language, and/or may further include a query language.Conventionally, PROLOG and other languages have been paired with querylanguages that work with data stored in some form of predicate logic.Conventional query languages follow a common pattern and use formulas(i.e., sentence like structures which include variables, like theformulas in our example language). However, the variables here are notquantified. Instead, in the parlance of predicate logic, they are“free.” This relates to an important difference between predicate logicused for academic study and its technical applications, which introducequeries. A key feature of predicate logic is its semantics, whichspecify how to determine if a sentence is true or false. Variables areassociated with quantifiers so that they can be interpreted within thesemantics. However, queries are not like statements. Although they mayreturn a value of true or false, they are not themselves true or falsebecause they are not declarative sentences, they are of a differentgrammatical category.

Query languages work by matching formulas against sentences. The core tothis process is that if the constants in the formula match against thecorresponding constants at the same position in the sentence, then thevariables in the formula will bind to the constants at the correspondingpositions in the sentence. Results are created by the formula matchingagainst all the stored sentences. PROLOG and technologies that supportthese query languages take advantage of deduction to make a powerfuladdition to query capabilities. Specifically, the queries will not matchjust against sentences that are explicitly stated, but also sentencesthat can be deduced. For example, if the query “Who is mortal?” could beexpressed against the data and rule statements in the example providedin the table above, the query could take the form “Mortal(?Y)”. Thisquery could not be answered with just Sentence 1 and Sentence 2.However, because “Mortal(Socrates)” can be deduced from them, then it ispossible to return a result where the variable “?Y” is bound to“Socrates.” This process of answering queries by matching formulasagainst both explicitly stated sentences and deduced sentences may bereferred to herein as “inference.”

A more unusual, but not novel, extension to predicate logic in theexample language utilized by system 100 described herein is theinclusion of “quotation.” The Cyc project uses a form of quotation inits extended form of predicate logic which it uses (see Matuszek, C. etal., “An Introduction to the Syntax and Content of Cyc”). Basically,“quotation” is a feature of languages that allows them to referenceexpressions of the language as linguistic expressions, as opposed totheir standard denotations. The following sentences illustrate thedifference in meaning that comes from using quotation:

Dogs are animals.

“Dogs” is a plural noun.

Dogs are nouns.

The first sentence is stating a fact about a type of living creature.The second sentence is talking about a word in the English language. Thethird sentence is false and sounds odd because it is attempting to talkabout linguistic expressions (by referencing the linguistic category ofnouns) without invoking quotation.

An aim of the technical solution provided by the systems and methodsdescribed herein is to use predicate logic to make statements aboutqueries and rule statements. If the features of the queries and rulescan be stated or just deduced, then questions can be answered aboutqueries and rule statements. Following the conventions of predicatelogic and how sentences and formulas are constructed, this would requirethat queries and rule statements become names. Quotation provides amechanism to turn queries and rule statements into names, because thequoted form is a reference to the query or rule statement itself.

For quotation to be fully integrated, it must also play a role indeductions. Because quoted expressions act as names, deduction wouldmost naturally be supported via an extension to how quantification worksfor the extended language. This would mean a set of variables,quantifiers, and deduction patterns for quotation. However, forquantification to work in conjunction with quotation, the common notionof quotation must be adapted. That is, if a variable appears in thecontext of a quote, is it quoted or is it being used as a variable? If avariable in a quote is being used as a variable, then the variableshould be covered by instantiation (i.e., the deduction patternintroduced above for quantification). However, if the variable is beingquoted, then the variable should not be able to be instantiated becauseit is not a normal variable—it is quoted. In order to distinguish thesetwo cases, the extension to predicate logic would include two types ofquotation, “bound quotes” and “open quotes,” and a new class ofvariables—“quote variables.”

“Quote variables” are a distinct class of variables that can only appearwithin the context of a quotation. Without this second class ofvariables, it would be unclear what variables within a quote are beingquoted and which ones could be instantiated. Introducing the secondclass enables normal variables and quote variables to appear in thecontext of a quotation without it being unclear which ones could beinstantiated (i.e., only the quote variables).

Bound quotes and open quotes are introduced to help clarifyquantification deduction patterns. If the goal of introducing quotationis to allow us to speak about any expression in the language, then thiswould also apply to quotes and quote variables. A “bound quote” is aquote where none of the contained variables, neither normal nor quotevariables, can be instantiated. An “open quote” is a quote where thequote variables but not the normal variables can be instantiated.

Accordingly as discussed herein, the language utilized by system 100 maycomprise an extended form of predicate logic that includes one or moreof the following features: (i) functional terms; (ii) a query languagethat follows the same basic structure for how data is stored but whichuses variables to specify bindings within results (i.e., sentences andformulas); (iii) a syntax for quotation with two forms of quotation(i.e., open quotation and bound quotation) and/or a class of variables(i.e., “quote variables”) with associated quantifiers; and (iv)deduction patterns for bound quotes, open quotes, and quote variables,including instantiation.

Example Flowchart of Processes

FIG. 2 illustrates an example of a process 200 of receiving andprocessing queries, according to an implementation of the invention. Theoperations of process 200 presented below are intended to beillustrative and, as such, should not be viewed as limiting. In someimplementations, process 200 may be accomplished with one or moreadditional operations not described, and/or without one or more of theoperations discussed. In some implementations, two or more of theoperations may occur substantially simultaneously. The describedoperations may be accomplished using some or all of the systemcomponents described in detail above.

In some implementations, process 200 may be implemented in one or moreprocessing devices (e.g., a digital processor, an analog processor, adigital circuit designed to process information, a central processingunit, a graphics processing unit, a microcontroller, an analog circuitdesigned to process information, a state machine, and/or othermechanisms for electronically processing information). The one or moreprocessing devices may include one or more devices executing some or allof the operations of process 200 in response to instructions storedelectronically on one or more electronic storage mediums. The one ormore processing devices may include one or more devices configuredthrough hardware, firmware, and/or software to be specifically designedfor execution of one or more of the operations of process 200. Invarious implementations, the operations of process 200 may be performedby a query server (which may be the same as or similar to querycomponent 118).

In an operation 202, process 200 may include receiving a named query.For example, a query server may receive a named query from an entityover a network connection. The entity could comprise one of a variety ofsources. For example, the query server may receive a named query from anapplication server (or application component 124) based on interactionswith an application browser, the query server may receive a named queryfrom an induction server (or induction component 130) to collect data tosupport the rule generation process, and/or the query server may receivefrom service endpoint 132 a named query that service endpoint 132 hadconverted from another messaging protocol.

In an operation 204, process 200 may include constructing a namedauthorization query for the entity based on the named query received.The named authorization query may comprise a standard query which asks,“Is this entity authorized to ask this named query?” In an operation206, process 200 may include sending the named authorization query to aninference engine. For example, the query server may send the namedauthorization query to an associated inference engine (i.e., inferenceengine 122). The associated inference engine may be a component of thequery server or the inference engine could have a network connection tothe query server and have authenticated the query server so that it isauthorized to perform operations with the inference engine. In variousimplementations, the inference engine may be configured to execute itsstandard process described further herein with respect to FIG. 4, andthen return the result(s) of the authorization query to the queryserver.

In an operation 208, process 200 may include responding to theauthorization result(s). If the authorized query failed (i.e., theinference engine determines that the entity is not authorized to performthe query), process 200 may proceed to operation 210. If theauthorization query succeeded, process 200 may proceed to operation 212.In operation 210, process 200 may include returning an error messageindicated that the authorization query failed. For example, the queryserver may be configured to send, via a network connection, a messageback to the entity that the authorization failed. In someimplementations, operation 210 may end process 200 for the entity withrespect to the named query.

In an operation 212, process 200 may include sending the named query tothe inference engine. For example, the query server may send the namedquery received in operation 202 to inference engine 122. In variousimplementations, the inference engine may be configured to execute itsstandard process described further herein with respect to FIG. 4, andthen return the result(s) of the named query to the query server. In anoperation 214, process 200 may include returning the result(s) of thenamed query to the entity. For example, the query server may return theresult(s) of the named query to the entity via a network connection.

FIG. 3 illustrates an example of a process 300 of receiving andprocessing operations, according to an implementation of the invention.The operations of process 300 presented below are intended to beillustrative and, as such, should not be viewed as limiting. In someimplementations, process 300 may be accomplished with one or moreadditional operations not described, and/or without one or more of theoperations discussed. In some implementations, two or more of theoperations may occur substantially simultaneously. The describedoperations may be accomplished using some or all of the systemcomponents described in detail above.

In some implementations, process 300 may be implemented in one or moreprocessing devices (e.g., a digital processor, an analog processor, adigital circuit designed to process information, a central processingunit, a graphics processing unit, a microcontroller, an analog circuitdesigned to process information, a state machine, and/or othermechanisms for electronically processing information). The one or moreprocessing devices may include one or more devices executing some or allof the operations of process 300 in response to instructions storedelectronically on one or more electronic storage mediums. The one ormore processing devices may include one or more devices configuredthrough hardware, firmware, and/or software to be specifically designedfor execution of one or more of the operations of process 300. Invarious implementations, the operations of process 300 may be performedby an operation server (which may be the same as or similar to operationcomponent 120).

In an operation 302, process 300 may include receiving a namedoperation. For example, an operation server may receive a namedoperation from an entity over a network connection. The entity couldcomprise one of a variety of sources. For example, the operation servermay receive a named operation from an application server (or applicationcomponent 124) based on interactions with an application browser, theoperation server may receive a named operation from an induction server(or induction component 130) to store the results of the inductionprocess, and/or the operation server may receive from service endpoint132 a named operation that service endpoint 132 had converted fromanother messaging protocol.

In an operation 304, process 300 may include constructing a namedauthorization query for the entity based on the named operationreceived. The named authorization query may comprise a standard querywhich asks, “Is this entity authorized to perform this named operation?”In an operation 306, process 300 may include sending the namedauthorization query to an inference engine. For example, the operationserver may send the named authorization query to an associated inferenceengine (i.e., inference engine 122). The associated inference engine maybe a component of the operation server or the inference engine couldhave a network connection to the operation server and have authenticatedthe operation server so that it is authorized to perform operations withthe inference engine. In various implementations, the inference enginemay be configured to execute its standard process described furtherherein with respect to FIG. 4, and then return the result(s) of theauthorization query to the operation server.

In an operation 308, process 300 may include responding to theauthorization result(s). If the authorized query failed (i.e., theinference engine determines that the entity is not authorized to performthe operation), process 300 may proceed to operation 310. If theauthorization query succeeded, process 300 may proceed to operation 312.In operation 310, process 300 may include returning an error messageindicating that the authorization query failed. For example, theoperation server may be configured to send, via a network connection, amessage back to the entity that the authorization failed. In someimplementations, operation 310 may end process 300 for the entity withrespect to the named operation.

In an operation 312, process 300 may include constructing a named dataintegrity query based on the named operation received. For example, theoperation server may construct a named data integrity query from thenamed operation which was provided by the entity. The named dataintegrity query may comprise, for example, a standard query which asks,“Does this named operation satisfy or violate its associated dataintegrity rules?” In an operation 314, process 300 may include sendingthe named data integrity query to an associated inference engine. Basedon the functor of the named operation, a set of rules specific to thatoperation may be assembled such that the inference is specific to thatnamed operation. For example, the operation server may send the nameddata integrity query to inference engine 122. In variousimplementations, the inference engine may be configured to execute itsstandard process described further herein with respect to FIG. 4, andthen return the result(s) of the named data integrity query to theoperation server. In an operation 316, process 300 may includeresponding to the data integrity check result(s). If the data integrityquery failed (i.e., the named operation violates one or more dataintegrity requirement(s)), process 300 may proceed to operation 318. Ifthe data integrity query succeeded, process 300 may proceed to operation320. In an operation 318, process 300 may include returning an errormessage indicating that the data integrity check failed. For example,the operation server may be configured to send, via a networkconnection, a message back to the entity that the data integrity checkfailed. In some implementations, operation 318 may end process 300 forthe entity with respect to the named operation.

In an operation 320, process 300 may include sending the named operationto an associated inference engine. For example, the operation server maysend the named operation (i.e., the named operation received inoperation 302) to inference engine 122. In various implementations, theinference engine may be configured to execute its standard processdescribed further herein with respect to FIG. 4, and then return theresult(s) of the named operation to the operation server. The queryresults here will specify what statements should be added to, deletedfrom, or modified within specific collections of statements in dataassociated with the system (e.g., data stored by data component 116).

In an operation 322, process 300 may include performing the operationsof the named operation received from the entity. For example, operationserver may be configured to make modifications to data stored based onthe named operation. In some implementations, the operation server mayinterface with the volume manager component 126, which is configured toidentify the location of the data servers that store the data to bemodified. In various implementations, the operation server may beconfigured to add the statements that should be added to the relevantcollections of data, delete the statements that should be deleted, andmodify the statements that should be modified. In an operation 324,process 300 may include returning a message that the operation succeededto the entity. For example, the operation server may be configured tosend, via a network connection, a message back to the entity that themodifications succeeded, potentially including references to thetransactions that occurred in response to the named operation. Invarious implementations, operation 324 may end the process for theoperation server with respect to the named operation.

FIG. 4 illustrates an example of a process 400 of utilizing inferencetrees to process named queries and operations, according to animplementation of the invention. The operations of process 400 presentedbelow are intended to be illustrative and, as such, should not be viewedas limiting. In some implementations, process 400 may be accomplishedwith one or more additional operations not described, and/or without oneor more of the operations discussed. In some implementations, two ormore of the operations may occur substantially simultaneously. Thedescribed operations may be accomplished using some or all of the systemcomponents described in detail above.

In some implementations, process 400 may be implemented in one or moreprocessing devices (e.g., a digital processor, an analog processor, adigital circuit designed to process information, a central processingunit, a graphics processing unit, a microcontroller, an analog circuitdesigned to process information, a state machine, and/or othermechanisms for electronically processing information). The one or moreprocessing devices may include one or more devices executing some or allof the operations of process 400 in response to instructions storedelectronically on one or more electronic storage mediums. The one ormore processing devices may include one or more devices configuredthrough hardware, firmware, and/or software to be specifically designedfor execution of one or more of the operations of process 400. Invarious implementations, the operations of process 400 may be performedby one or more processor components the same as or similar to inferenceengine 122 (shown in FIG. 1 and described herein).

In an operation 402, process 400 may include inferring full query andassociated rule statements. In various implementations, inference engine122 may be configured to obtain the named query or operation andperforms two steps. First, inference engine 122 may be configured to runan inference to determine the corresponding full query for the namedquery or operation. Second, inference engine 122 may be configured todetermine what rule statements, if any, should support the full queryand how those rule statements may be fit together (i.e., how theconsequents of one rule statement links the antecedent of another). Thisdata could be gathered in multiple ways. For example, inference engine122 may be configured to run a standard set of inferences against thedata associated with the system (e.g., data stored by data component116). In some implementations, inference engine 122 may be configured tointerface with volume manager component 126 to identify the location ofthe data needed. In some implementations, inference engine 122 may beconfigured to obtain the data by pulling from an inference tree cache134 previously constructed and serialized inference trees that allowinference engine 122 to skip the query step here and the assembling workof operation 404, and instead reconstruct the inference tree from itsserialized form and proceed to operation 406.

In an operation 404, process 400 may include assembling an inferencetree. In various implementations, operation 404 may begin with thequery. Rule statements whose consequent formulas, which can be linked toformulas in the query, may be connected first. Rule statements may berecursively linked to other rule statements, where the formulas in theantecedents of earlier rule statements are linked to formulas in theconsequents of later rules. As described herein, the result may comprisea tree-like structure of connected rule statements, which we will callan “inference tree.” The set of rule statements that make up theinference tree may be limited to those returned from the query performedin operation 402. In some implementations, a shortened form of this stepcould be performed if there is a cache of previously constructedinference trees that could be adapted to the current named query ornamed operation.

In an operation 406, process 400 may include executing the inferencetree against the stored data associated with the system. In variousimplementations, inference engine 122 may be configured to process theinference tree using the content stored by data component 116. Theinference engine 122 may be configured to interface with and/or rely onvolume manager component 126 to identify the location of the dataneeded. The process works from the rules that are at the “leaves” of theinference tree (i.e., their antecedents are not connected to any otherrule statements). These rules (or rule statements) that are at theleaves of the inference tree may be referred to as “terminal rulestatements.” For the terminal rule statements, there are no deducedsentences which inference engine 122 can use. Inference engine 122 mayonly use statements that are stored within the data and then deduce newstatements. After this point, there can be deduced statements and storedstatements within the stored data. Both sets of statements are now usedfor subsequent deductions performed with non-terminal rule statements(i.e., intermediary rule statements). This process recurses through thetree structure until results are being fed into the formulas withinqueries at the base of the inference tree. When this process finishes, aset of results may be provided for the query. There is a third possibleway that statements might become available for deduction. In someimplementations, inference engine 122 may include modules that allow itto compute certain statements without the statements being deduced orstored by data component 116. For example, if a rule statement reliesupon a mathematical calculation from data in other statements, thatcalculation may be expressed as a formula within a rule statement.Inference engine 122 may be configured to perform the calculation todetermine the binding for the relevant variables, rather than havingevery possible mathematical calculation stored in the data or trying todeduce the calculation. In various implementations, inference engine 122may include a wide range of modules for addressing these situationswithin its data.

In an operation 408, process 400 may include returning the result(s)generated from executing the inference tree against the stored dataassociated with the system. For example, inference engine 122 may beconfigured to return the result(s) to the entity that provided the namedquery or named operation via query component 118 or operation component120.

FIG. 5 illustrates an example of a process 500 of executing anapplication that has been described in data using the extended form ofpredicate logic language described herein and using the inference engineto process both queries and operations required to process user inputsand instantiate a page of the application, according to animplementation of the invention. The operations of process 500 presentedbelow are intended to be illustrative and, as such, should not be viewedas limiting. In some implementations, process 500 may be accomplishedwith one or more additional operations not described, and/or without oneor more of the operations discussed. In some implementations, two ormore of the operations may occur substantially simultaneously. Thedescribed operations may be accomplished using some or all of the systemcomponents described in detail above.

In some implementations, process 500 may be implemented in one or moreprocessing devices (e.g., a digital processor, an analog processor, adigital circuit designed to process information, a central processingunit, a graphics processing unit, a microcontroller, an analog circuitdesigned to process information, a state machine, and/or othermechanisms for electronically processing information). The one or moreprocessing devices may include one or more devices executing some or allof the operations of process 500 in response to instructions storedelectronically on one or more electronic storage mediums. The one ormore processing devices may include one or more devices configuredthrough hardware, firmware, and/or software to be specifically designedfor execution of one or more of the operations of process 500. Invarious implementations, the operations of process 500 may be performedby an application server and/or an application browser. As describedherein, the application component 124 may include an application serverand/or an application browser. Accordingly, the operations of process500 may be performed by one or more processor components the same as orsimilar to application component 124 (shown in FIG. 1 and describedherein).

In an operation 502, process 500 may include authenticating a user. Forexample, a user may attempt to log into an application browser. Theapplication browser may be configured to authenticate the user based ona username and password and/or other security credentials. In variousimplementations, the user may be authenticated by an associatedauthentication service.

In an operation 504, process 500 may include sending a default requestof the user to an application server. For example, the applicationbrowser may be configured to send the default request of the user to theapplication server in response to the user being authenticated. Invarious implementations, the application browser may be configured tostore a default request of a user. A common example may be a home pagewhich displays a list of applications to which the user has access.Alternatively, it could be configured to be a specific page which theuser had saved during a previous session. In various implementations,the default request may be composed of at least two elements: an orderedlist of zero or more named operations and zero-or-one named pages.Analogous to named queries and named operations, a “named page” maycomprise a functional term which is used to construct an inference. Invarious implementations, named pages may be used to run inferences todetermine a collection of content which the application browser willrender (e.g., via a client computing platform 104). In variousimplementations, the application browser may be analogous to a webbrowser, and a named page may be analogous to a web page. A keydistinction may be that the named page is not identifying a location ona network (e.g., a Uniform Resource Locator). Instead, a named pageidentifies a collection of information and interactions which can bedisplayed via the application browser (e.g., on client computingplatform 104).

In an operation 506, process 500 may include processing operationsassociated with the request. For example, the application server mayreceive the request and first process the named operations in order. Theapplication server may comprise an authenticated entity related to anoperation server (or operation component 120) described here. Theapplication server may be configured to send each named operation to theoperations server on behalf of the authenticated user (who will be thesubject of the authorization check). The operation server may beconfigured process each named operation as described with respect toprocess 300 depicted in FIG. 3. In cases where authorization or dataintegrity checks fail, the application server may be configured to storethe message from the operation server for inclusion in the returnmessage to the application browser. If the request included a namedpage, the application server may proceed to operation 508. Otherwise,process 500 may proceed to operation 512.

In an operation 508, process 500 may include running inferences for therequested page. For example, the application server may be configured toutilize the query server (or query component 118) to run inferences forthe requested page. If the request does contain a named page, theapplication server may be configured to construct named queries whichwill be used to determine the elements of the page, their content,layout, and formatting. In some implementations, there is not fixed setof elements which can appear in a page. For example, the types ofelements may range from simple texts and images, interactive buttonsthat enable them to navigate to new pages, common controls (e.g., listsdrop down menus, tables, etc.) and specialized interactivevisualizations (e.g., data visualizations or augmented realityapplications). In various implementations, the named queries aredesigned to infer the individual elements which should appear in thepage and each element's details. The rules that are associated with thenamed page and which get assembled into the inference tree will havebeen designed to supply all needed details for each element. Becausedifferent types of elements can be described with different vocabulary,multiple named queries may need to be run in order to gather results forall the elements within the page. In various implementations, theapplication server may be configured to run all the named queries viathe query server. In various implementations, the content of the elementdepends on the type of element. For simple labels, it may be just thetext that it displays. For images, it may be an identifier of the imagefile to display. For navigation buttons, it may be the named page thatthe browser would display next. For buttons where the user is inputtingnew data, the content may be details on how to create a named operationbased on the user's input. For example, an interactive element where auser can enter text could be used for different named operations ondifferent pages. On one page, users could use it to enter their name. Onothers, users could use the same interactive element to enter taskdescriptions into a to-do list. The different semantics of the elementon different pages is determined by the different named operation withwhich they are associated on those different pages. In variousimplementations, the application server may be configured to send thenamed queries to the query server on behalf of the authenticated user(who will be the subject of the authorization check). For each query,the query server may be configured to go through operations 202-214 ofprocess 200. If the authorization check fails, the application servermay be configured to store that message from the query server forinclusion in the return message to the application browser. Otherwise,the query server may be configured to complete the process and returnsthe query results to the application server.

In an operation 510, process 500 may include formatting the queryresult(s) into a description of the requested page. For example, theapplication server may be configured to format the query result(s) intoa description of the requested page. If the request included a namedpage and authorization was successful, the application server may beconfigured to receive query results in the standard format via which thequery server returns all results. In various implementations, theapplication server may be configured to process the result(s) to compilethe result(s) into a standard format that the application browser isconfigured to interpret and then render to the screen.

In an operation 512, process 500 may include receiving a message fromthe application server. For example, the application server may beconfigured to combine any message from named operations and theformatted query result(s) for the named page's content into a singlemessage. The application server may be configured to return the messageto the application browser over a network connection.

In an operation 514, process 500 may include processing the message. Forexample, the application browser may be configured to process themessage received back from the application server. In variousimplementations, the application browser process may branch based on thecontent of the message received back from the application server. Ifthere were any failures with processing operations or inferences for anamed page (e.g., failed authorizations), the application browser mayproceed to operation 516. If the request included a new named page thatwas successfully processed, the application browser may proceed tooperation 518.

In an operation 516, process 500 may include displaying an errormessage. For example, the application browser may be configured todisplay a message describing the nature of the error which occurred and,if appropriate, interactive controls with actions that the user cantake. Depending on the nature of the error, the application browser maybe configured to proceed to operation 518. For example, applicationbrowser may be configured to display the last page it rendered.

In an operation 518, process 500 may include displaying a new page. Forexample, the application browser may be configured to extract each ofthe elements from the page description. In various implementations,application browser may be configured to instantiate appropriatesoftware modules for each type of element. The instantiated modules maybe configured to process the content and styling that have been linkedto that element. In various implementations, the application browser maybe configured to render all the associated modules to the display.

In an operation 520, process 500 may include receiving user inputassociated with the new page. For example, the user may interact withthe page displayed in the application browser to navigate to a pageand/or update data. In various implementations, the elements of the pagemay support different types of interaction (i.e., data update operationsversus navigations to new pages). Based on the user's goals, the usermay interact with the elements displayed in the page. The instantiatedmodules may be configured to interpret the user's input. If the inputrequires interaction with the application server to update or query newdata, the modules may be configured to notify the application browser ofthe request to send to the application server.

In an operation 522, process 500 may include sending the selectedrequest to the application server. For example, the application browsermay be configured to send the selected request to the applicationserver. In various implementations, the application browser may beconfigured to obtain the request from the activated page element moduleand forward the request to the application server. Responsive to therequest being forwarded to the application server, process 500 mayreturn to operation 506 and proceed accordingly.

The various processing operations and/or data flows depicted in FIGS.2-5 (and in the other drawing figures) are described in greater detailherein. The described operations may be accomplished using some or allof the system components described in detail above and, in someimplementations, various operations may be performed in differentsequences and various operations may be omitted. Additional operationsmay be performed along with some or all of the operations shown in thedepicted flow diagrams. One or more operations may be performedsimultaneously. Accordingly, the operations as illustrated (anddescribed in greater detail below) are exemplary by nature and, as such,should not be viewed as limiting.

System Advantages

The systems and methods described herein address the technicalproblem(s) caused by the disconnect between languages for data, queries,and programming, which, for example, may result in various additionalcosts risks for organizations. The systems and methods described hereinaddress the technical problem(s) described herein with an extended formof predicate logic to store data, queries, and operations in a commonway and a technical implementation that allows users to manage and runqueries on the data, queries, and operations. However, the technicalsolution embodied by these systems and methods also enables a broaderset of benefits.

For example, organizations are composed of business systems which arefurther composed of people, processes, and technology to achieve somegoal (e.g., profit making, public services, etc.). Organizations investin these business systems and need a return on investment or otherbenefit from those investments. Technology investments include wideranges of equipment. For information technology, this may typicallyinclude hardware and software. However, technology can require its ownbusiness systems, each devoted not to the broader organization's missionbut to the management of information technology used within theorganizations main business systems. These IT-focused business systemsinvolve dedicated people, processes, and additional technology.

For example, IT development and operations are IT-focused businesssystems for creating, deploying, and maintaining new features andfunctionality. These IT-focused business systems have processes staffedby several roles (e.g., managers, engineers, designers, and testers) aswell as technology these roles needs to complete their work. Whenorganizations have large enough information technology investments,additional IT-focused systems typically include data management, ITarchitecture, and IT portfolio management. As business systems, each mayhave dedicated people, processes, and technology. When an organizationhas a large enough IT portfolio, these IT-focused business systems aretypically managed by a chief information officer (CIO). The CIO would beresponsible for delivering these IT capabilities but also for deliveringa return on investment.

The growth of IT-focused business systems creates a challenge for CIOsto deliver returns on investments. In short, IT-focused business systemsare often overhead, because they are not geared towards achieving theorganizations' core mission. The technology which the core businesssystems use directly supports the organizations missions. IT-focusedbusiness systems are focused on the organizations' technology footprint.This indirect connection to organizations' missions makes it difficultfor these IT-focused systems to deliver a positive return on investment.

The best strategy for maximizing the return on investment for theseIT-focused business systems is to minimize their costs, as that lowersthe required level of benefits needed for a positive return.Alternatively, the strategy minimizes the negative impact when there areno quantifiable benefits. In general, organizations whose core missionis not the delivery of information technology (i.e., businesses that donot sell software) should be trying to minimize the size and scope ofthese IT-focused business systems. Since most organizations are notdedicated to delivering information technology, this applies to mostorganizations.

The technology embodied in the systems and methods described hereinrepresents a novel solution which CIOs or other managers oforganizations' information technology footprints can adopt to maximizethe return on their investment in business systems. The focus would beon minimizing the cost, but it would do so by radically shifting themixture of people, processes, and technology that go into businesssystems (whether core or IT-centric).

The main beneficiaries may be organizations that have a large ITfootprint, and which require various IT-focused business systems. Rightnow, IT-focused business systems require specialized skills andexpertise such that specific technical personnel must be hired for anorganization to acquire those skills. This means that the IT-focusedbusiness systems depend on expensive and dedicated resources (i.e.,resources whose skills cannot be applied within other business systems).

The technology embodied in the systems and methods described herein mayrequire a different and much smaller set of skills. For example, thefoundational skill may comprise an understanding of predicate logic—askill which may be gained in a one semester introductory college class.Skills whose foundations are based on a single class are much differentthan skills for which there is an entire major. By lowering the skillrequirements to use this solution, organizations have a new option forhow to create business systems. By replacing standard technologies oftoday with the new technology described herein, organizations would beable to change the range of persons who could complete the system. Thatis, there are different combinations of people and processes that couldbe matched with this technology, creating options for new businesssystem configurations. For example, existing personnel with specificskills (e.g., accounting) could be trained up on predicate logic and theusage of this technology. Alternatively, people who specialize in thistechnology could be used across business systems because understandingdifferent applications that might be built on this technology onlydepends on understanding the statements, queries, and rules involved.They no longer need to contend with diverse languages, frameworks orengineering styles that are part of utilizing current technologies.

Example Implementation—Compliance

A concrete example of the utility of the systems and methods describedherein is the potential to transform compliance processes around suchtopics as privacy data, such as personally identifiable information(PII) or personal health information (PHI). Because of the utilizationof predicate logic, this topic may begin with understanding whichpredicates represent relevant forms of privacy data. For example, apredicate might link a person to their Social Security Number. Thus,sentences using that predicate would constitute PII. Another predicatemight link a person to a medical event. Thus, sentences using thatpredicate would constitute PHI. This new information (i.e., whatpredicates constitute PII or PHI) could also be added as descriptions ofthe predicates themselves. This would then allow for the construction ofqueries to identify all of the predicates that are related to PII orPHI. The ability to query for predicates that constitute PII or PHI mayenable the creation of queries about the data, queries, inferences, andoperations involved in an application that involve privacy data. Forexample, an evaluator could run queries to identify what queries utilizePII predicates or which operations add or modify statements using PHIpredicates. Because these are the queries and operations whichconstitute applications built on this technology, the evaluator wouldhave an accurate method for investigating activities around privacy datathat may be fully automated.

Example Implementation—Enterprise Architecture

Another concrete example of the utility of the systems and methodsdescribed herein is the potential to transform Chief Information Officerorganizations. A specific function within CIO organizations isenterprise architecture. A key task of enterprise architects is todocument the range of IT applications and systems within theorganization and how they support business functions. For example, itcould track the various financial applications and financial functionsthey support (i.e., accounting, budgeting, expense tracking, etc.). Theenterprise architecture(s) enable the CIO to track the status of new andongoing IT investments.

Enterprise architects must provide a detailed and accurate descriptionof the IT footprint. This includes not just the systems, but the datathey contain, the services they provide to different organizationalfunctions, and their connections to other systems. Enterprise architectsuse dedicated tools, create unique data, and have their own specificprocesses. They are a prime example of an IT-focused business system: asystem that exists to support an organization's IT footprint as opposedto the organization's core mission. Enterprise architecture can bedifficult to create because the architects need to translate availabledocumentation about the IT systems into enterprise architecture, butonly if that documentation is available. As mentioned before, thisdocumentation often does not exist, or it might be out of date if it hasnot been consistently updated to track changes in IT systems. If theenterprise architecture is inaccurate or incomplete it loses significantvalue, thereby reducing the return on investment in an enterprisearchitecture program.

The systems and methods described herein may radically change the needfor, and role of, enterprise architecture. In particular, the componentsof the technology described herein may be commoditized and generic. Forexample, they may not be unique IT systems. Based on the size of anorganization and the scale of its data, organizations may install morecomponents to scale, with all the components being the same. Further,applications and systems built using the technology described hereinwould be stored as data in predicate logic. Storing them as dataeliminates the need to translate IT documentation into enterprisearchitecture. The data which the enterprise architects are seeking isthe same data that composes the applications built in the extended formof predicate logic. The enterprise architects can run queries to getcomplete and accurate descriptions of the data, queries, inferences, andoperations which compose those applications. Further, as needed, theenterprise architects can supplement the data that describes theapplication(s) with additional data to connect those applications tobusiness functions and other elements of the enterprise. This feature ofthe invention eliminates the need for enterprise architects to havedistinct tools and data that they need to update constantly toaccurately reflect changes in the IT footprint. This greatly increasesthe productivity of enterprise architects. Thus, the cost of anenterprise architecture program would be reduced because work anddedicated technologies may be eliminated, while enterprise architects'effectiveness is increased.

Enterprise architecture and compliance are just two examples. There area range of potential benefits from this technology by enablingorganizations to change how they construct business systems. Thesimplicity of the technology allows organizations to gain various formsof cost savings and to improve the effectiveness and efficiency of theirbusiness systems—most notably their IT-focused business systems.

For purposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of the description. It will beappreciated by those having skill in the art that the implementationsdescribed herein may be practiced without these specific details or withan equivalent arrangement. Accordingly, it is to be understood that thetechnology is not limited to the disclosed implementations, but, on thecontrary, is intended to cover modifications and equivalent arrangementsthat are within the spirit and scope of the appended claims. Forexample, it is to be understood that the present technology contemplatesthat, to the extent possible, one or more features of any implementationcan be combined with one or more features of any other implementation.

Implementations of the disclosure may be made in hardware, firmware,software, or any suitable combination thereof. Aspects of the disclosuremay be implemented as instructions stored on a machine-readable medium,which may be read and executed by one or more processors. Amachine-readable medium may include any mechanism for storing ortransmitting information in a form readable by a machine (e.g., acomputing device). For example, a tangible computer readable storagemedium may include read only memory, random access memory, magnetic diskstorage media, optical storage media, flash memory devices, and others,and a machine-readable transmission media may include forms ofpropagated signals, such as carrier waves, infrared signals, digitalsignals, and others. Firmware, software, routines, or instructions maybe described herein in terms of specific exemplary aspects andimplementations of the disclosure, and performing certain actions.

The various instructions described herein are exemplary only. Otherconfigurations and numbers of instructions may be used, so long as theprocessor(s) are programmed to perform the functions described herein.The description of the functionality provided by the differentinstructions described herein is for illustrative purposes, and is notintended to be limiting, as any of instructions may provide more or lessfunctionality than is described. For example, one or more of theinstructions may be eliminated, and some or all of its functionality maybe provided by other ones of the instructions. As another example,processor(s) 112 may be programmed by one or more additionalinstructions that may perform some or all of the functionalityattributed herein to one of the computer-readable instructions.

Although processor(s) 112 are illustrated in FIG. 1 as a singlecomponent, this is for illustrative purposes only. In someimplementations, processor(s) 112 may comprise multiple processingunits. These processing units may be physically located within the samedevice, or processor(s) 112 may represent processing functionality ofmultiple devices operating in coordination. In some implementations, oneor more processors 112 may be implemented by a cloud of computingplatforms operating together as one or more processors 112. Processor(s)112 be configured to execute one or more components by software;hardware; firmware; some combination of software, hardware, and/orfirmware; and/or other mechanisms for configuring processingcapabilities on processor(s) 112.

As used herein, the term “component” may refer to any component or setof components that perform the functionality attributed to thecomponent. This may include one or more servers or physical processorsduring execution of computer-readable instructions, thecomputer-readable instructions, circuitry, hardware, storage media, orany other components. Furthermore, it should be appreciated thatalthough the various instructions are illustrated in FIG. 1 as beingco-located within a single processing unit, in implementations in whichprocessor(s) 112 include multiple processing units, one or moreinstructions may be executed remotely from the other instructions.

The various instructions described herein may be stored in a storagedevice, which may comprise random access memory (RAM), read only memory(ROM), and/or other memory. For example, electronic storage 140 maycomprise any tangible computer readable storage medium, including randomaccess memory, read only memory, magnetic disk storage media, opticalstorage media, flash memory devices, and/or other memory configured tocomputer-program instructions. In various implementations, electronicstorage 140 may be configured to store the computer program instructions(e.g., the aforementioned instructions) to be executed by the processorsas well as data that may be manipulated by the processors.

One or more databases may be stored in one or more storage devices ofsystem 100 (e.g., electronic storage 140). For example, one or morecollections of statements of predicate logic may be stored in the one ormore databases, as described herein. The databases described herein maybe, include, or interface to, for example, graph databases, NoSQLdatabases, OracleTM relational databases sold commercially by OracleCorporation, Informix™, DB2 (Database 2), or other data storage,including file-based, or query formats, platforms, or resources such asOLAP (On Line Analytical Processing), SQL (Structured Query Language), aSAN (storage area network), Microsoft Access™, and/or other . Otherdatabases, such as Informix™, DB2 (Database 2) or other data storage,including file-based, or query formats, platforms, or resources such asOLAP (On Line Analytical Processing), SQL (Structured Query Language), aSAN (storage area network), Microsoft Access™, and/or other types ofdatabases now known or future developed. The database may comprise oneor more such databases that reside in one or more physical devices andin one or more physical locations. The database may store a plurality oftypes of data and/or files and associated data or file descriptions,administrative information, or any other data.

The various components illustrated in FIG. 1 may be coupled to at leastone other component via a network 102, which may include any one or moreof, for instance, the Internet, an intranet, a PAN (Personal AreaNetwork), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN(Storage Area Network), a MAN (Metropolitan Area Network), a wirelessnetwork, a cellular communications network, a Public Switched TelephoneNetwork, and/or other network. In FIG. 1, as well as in other drawingFigures, different numbers of entities than those depicted may be used.Furthermore, according to various implementations, the componentsdescribed herein may be implemented in hardware and/or software thatconfigure hardware.

In some instances, well-known structures and devices are shown in blockdiagram form in order to avoid unnecessarily obscuring the description.In other instances, functional block diagrams and flow diagrams areshown to represent data and logic flows. The components of blockdiagrams and flow diagrams (e.g., modules, blocks, structures, devices,features, etc.) may be variously combined, separated, removed,reordered, and replaced in a manner other than as expressly describedand depicted herein.

Reference in this specification to “one implementation”, “animplementation”, “some implementations”, “various implementations”,“certain implementations”, “other implementations”, “one series ofimplementations”, or the like means that a particular feature, design,structure, or characteristic described in connection with theimplementation is included in at least one implementation of thedisclosure. The appearances of, for example, the phrase “in oneimplementation” or “in an implementation” in various places in thespecification are not necessarily all referring to the sameimplementation, nor are separate or alternative implementations mutuallyexclusive of other implementations. Moreover, whether or not there isexpress reference to an “implementation” or the like, various featuresare described, which may be variously combined and included in someimplementations, but also variously omitted in other implementations.Similarly, various features are described that may be preferences orrequirements for some implementations, but not other implementations.

The language used herein has been principally selected for readabilityand instructional purposes, and it may not have been selected todelineate or circumscribe the inventive subject matter. Otherimplementations, uses, and advantages of the invention will be apparentto those skilled in the art from consideration of the specification andpractice of the invention disclosed herein. The specification should beconsidered exemplary only, and the scope of the invention is accordinglyintended to be limited only by the following claims.

What is claimed is:
 1. A system configured to utilize a single sequenceof operations for querying data and processing operations on the data,the system comprising: a memory configured to store data associated withthe system, wherein the data is stored in a form of predicate logicextended to include quotation; and one or more physical processorsprogrammed by one or more computer program instructions that, whenexecuted, configure the one or more physical processors to: receiveinput from an entity including a named query or a named operation;determine a corresponding full query for the named query or namedoperation; identify a first set of rule statements including consequentformulas linked to a formula in the full query; identify a second set ofrule statements including consequent formulas linked to antecedentformulas in the first set of rule statements; assemble an inference treecomprising rule statements recursively linked to the full query, whereinthe rule statements of the inference tree include at least the first setof rule statements and the second set of rule statements; recursivelyapply the rule statements of the inference tree to the stored data; andgenerate results of the full query based on the application of the rulestatements of the inference tree to the stored data.
 2. The system ofclaim 1, wherein to apply the rule statements of the inference tree tothe stored data, the one or more physical processors are configured to:bind formulas in terminal rule statements of the inference tree to thestored data, wherein a first set of deduced results is generated basedon the terminal rule statements; and bind formulas in at least a firstset of intermediary rule statements of the inference tree to the storeddata and the first set of deduced results, wherein a second set ofdeduced results is generated based on the first set of intermediary rulestatements; and bind formulas in at least a second set of intermediaryrule statements of the inference tree to the stored data and the secondset of deduced results, wherein the results of the full query aregenerated when formulas in the full query are applied to stored data anddeduced results previously generated based on intermediary rulestatements.
 3. The system of claim 1, wherein the input comprises anamed query and the results of the full query comprise results of thenamed query, wherein the one or more physical processors are furtherconfigured to return the results of the named query to the entity. 4.The system of claim 1, wherein the input comprises a named operation andthe results of the full query comprise identified statements to bemodified by the named operation, wherein the one or more physicalprocessors are further configured to: perform one or more operations ofthe named operation on the identified statements, the one or moreoperations comprising adding, removing, or modifying the identifiedstatements based on the named operation; and return a message to theentity comprising an indication that the named operation has beencompleted.
 5. The system of claim 1, wherein the one or more physicalprocessors are further configured to: construct a named authorizationquery for the entity based on the input received; assemble a secondinference tree comprising rule statements recursively linked to thenamed authorization query; recursively apply the rule statements of thesecond inference tree to the stored data; and determine whether theentity is authorized to ask the named query or perform the namedoperation based on the application of the rule statements of the secondinference tree to the stored data.
 6. The system of claim 4, wherein theinput comprises a named operation, and wherein responsive to adetermination that the entity is authorized to perform the namedoperation, the one or more physical processors are further configuredto: construct a named data integrity query based on the named operation;assemble a third inference tree comprising rule statements recursivelylinked to the named data integrity query; recursively apply the rulestatements of the third inference tree to the stored data; and determinewhether the named operation satisfies data integrity rules associatedwith the named operation based on the application of the rule statementsof the third inference tree to the stored data.
 7. The system of claim1, wherein the entity comprises a user and the input comprises a defaultrequest sent to an application server in response to the user attemptingto log into an application via an application browser, the defaultrequest including at least one named query and the generated resultscomprising results of the at least one named query, wherein the one ormore physical processors are further configured to: format the resultsof the at least one named query into a format the application browser isconfigured to interpret; provide the formatted results to theapplication browser; and render a page of the application browser in adisplay based on the formatted results.
 8. The system of claim 6,wherein the one or more physical processors are further configured to:receive a user request associated with the new page; assemble a secondinference tree comprising rule statements recursively linked to a namedquery associated with the user request; recursively apply the rulestatements of the second inference tree to the stored data; generateresults of the named query based on the application of the rulestatements of the second inference tree to the stored data; and cause anupdated page of the application browser to be rendered in the displaybased on the results of the named query.
 9. The system of claim 1,wherein the input is received from the entity via another system usingan alternative messaging protocol, wherein the one or more physicalprocessors are further configured to: translate the received input intothe named query or the named operation.
 10. The system of claim 1,wherein the one or more physical processors are further configured to:retrieve a serialized inference tree from a cache configured to storeinference trees created based on named queries or named operations,wherein the inference tree comprising rule statements recursively linkedto the full query is assembled based on the serialized inference treeretrieved from the cache.
 11. A method for utilizing a single sequenceof operations for querying data and processing operations on the data,the method being implemented on a computer system having one or morephysical processors and a memory configured to store data associatedwith the system in a form of predicate logic extended to includequotation, the method comprising: receiving input from an entityincluding a named query or a named operation; determining acorresponding full query for the named query or named operation;identifying a first set of rule statements including consequent formulaslinked to a formula in the full query; identifying a second set of rulestatements including consequent formulas linked to antecedent formulasin the first set of rule statements; assembling an inference treecomprising rule statements recursively linked to the full query, whereinthe rule statements of the inference tree include at least the first setof rule statements and the second set of rule statements; recursivelyapplying the rule statements of the inference tree to the stored data;and generating results of the full query based on the application of therule statements of the inference tree to the stored data.
 12. The methodof claim 11, wherein applying the rule statements of the inference treeto the stored data comprises: binding formulas in terminal rulestatements of the inference tree to the stored data, wherein a first setof deduced results is generated based on the terminal rule statements;and binding formulas in at least a first set of intermediary rulestatements of the inference tree to the stored data and the first set ofdeduced results, wherein a second set of deduced results is generatedbased on the first set of intermediary rule statements; and bindingformulas in at least a second set of intermediary rule statements of theinference tree to the stored data and the second set of deduced results,wherein a third set of deduced results is generated based on the secondset of intermediary rule statements wherein the results of the fullquery are generated when formulas in the full query are bound to thestored data and deduced results previously generated based onintermediary rule statements.
 13. The method of claim 11, wherein theinput comprises a named query and the results of the full query compriseresults of the named query, the method further comprising returning theresults of the named query to the entity.
 14. The method of claim 11,wherein the input comprises a named operation and the results of thefull query comprise identified statements to be modified by the namedoperation, the method further comprising: performing one or moreoperations of the named operation on the identified statements, the oneor more operations comprising adding, removing, or modifying theidentified statements based on the named operation; and returning amessage to the entity comprising an indication that the named operationhas been completed.
 15. The method of claim 11, the method furthercomprising: constructing a named authorization query for the entitybased on the input received; assembling a second inference treecomprising rule statements recursively linked to the named authorizationquery; recursively applying the rule statements of the second inferencetree to the stored data; and determining whether the entity isauthorized to ask the named query or perform the named operation basedon the application of the rule statements of the second inference treeto the stored data.
 16. The method of claim 15, wherein the inputcomprises a named operation, and wherein responsive to a determinationthat the entity is authorized to perform the named operation, the methodfurther comprises: constructing a named data integrity query based onthe named operation; assembling a third inference tree comprising rulestatements recursively linked to the named data integrity query;recursively applying the rule statements of the third inference tree tothe stored data; and determining whether the named operation satisfiesdata integrity rules associated with the named operation based on theapplication of the rule statements of the third inference tree to thestored data.
 17. The method of claim 11, wherein the entity comprises auser and the input comprises a default request sent to an applicationserver in response to the user attempting to log into an application viaan application browser, the default request including at least one namedquery and the generated results comprising results of the at least onenamed query, wherein the method further comprises: formatting theresults of the at least one named query into a format the applicationbrowser is configured to interpret; providing the formatted results tothe application browser; and rendering a page of the application browserin a display based on the formatted results.
 18. The method of claim 17,the method further comprising: receiving a user request associated withthe new page; assembling a second inference tree comprising rulestatements recursively linked to a named query associated with the userrequest; recursively applying the rule statements of the secondinference tree to the stored data; generating results of the named querybased on the application of the rule statements of the second inferencetree to the stored data; and causing an updated page of the applicationbrowser to be rendered in the display based on the results of the namedquery.
 19. The method of claim 11, wherein the input is received fromthe entity via another system using an alternative messaging protocol,the method comprising: translating the received input into the namedquery or the named operation.
 20. The method of claim 11, the methodfurther comprising: retrieving a serialized inference tree from a cacheconfigured to store inference trees created based on named queries ornamed operations, wherein the inference tree comprising rule statementsrecursively linked to the full query is assembled based on theserialized inference tree retrieved from the cache.